PATENT APPLICATION 
ATTORNEY DOCKET NO. 10002669-1 



HEWLETT-PACKARD COMPANY 
Intellectual Property Administration 
P.O. Box 272400 

Fort Collins, Colorado 80527-2400 

IN THE 

UNITED STATES PATENT AND TRADEMARK OFFICE 
Inventor(s): Raja Daoud, et al. Confirmation No.: 6164 



Application No.: 09/751,009 

Filing Date: December 29, 2000 



Examiner: Sail, El Hadji Malick 
Group Art Unit: 2157 



Title: APPARATUS AND METHOD FOR IDENTIFYING A REQUESTED LEVEL OF SERVICE FOR A TRANSACTION 

Mail Stop Appeal Brief-Patents 
Commissioner For Patents 
PO Box 1450 

Alexandria, VA 22313-1450 

TRANSMITTAL OF APPEAL BRIEF 

Transmitted herewith is the Appeal Brief in this application with respect to the Notice of Appeal filed on September 14, 2006 . 
The fee for filing this Appeal Brief is (37 CFR 1 .17(c)) $500.00. 

(complete (a) or (b) as applicable) 
The proceedings herein are for a patent application and the provisions of 37 CFR 1 .136(a) apply. 

□ (a) Applicant petitions for an extension of time under 37 CFR 1.136 (fees: 37 CFR 1.17(a)-(d)) for the total number of 
months checked below: 



I — - 1 st Month 
LJ $120 



□ 



2nd Month 
$450 



r— , 3rd Month 
LJ $1020 



,— , 4th Month 
L-l $1590 



□ The extension fee has already been filed in this application. 

[x](b) Applicant believes that no extension of time is required. However, this conditional petition is being made to provide for 
the possibility that applicant has inadvertently overlooked the need for a petition and fee for extension of time. 

Please charge to Deposit Account 08-2025 the sum of $ 500 . At any time during the pendency of this application, 
please charge any fees required or credit any over payment to Deposit Account 08-2025 pursuant to 37 CFR 1.2s! 
Additionally please charge any fees to Deposit Account 08-2025 under 37 CFR 1.16 through 1.21 inclusive, and any other 
sections in Title 37 of the Code of Federal Regulations that may regulate fees. A duplicate copy of this sheet is enclosed. 

[x] I hereby certify that this correspondence is being 



deposited with the United States Postal Service as first 
class mail in an envelope addressed to: 
Commissioner for Patents, Alexandria, VA 22313-1450 
Date of Deposit: September 14, 2006 
OR 

□ I hereby certify that this paper is being transmitted to 
the Patent and Trademark Office facsimile number 
(571)273-8300. 

Date of facsimile: 




Typed Name. 
Signature: 



^Chasity a Rossum 




Respectfully submitted, 
Raja Daqi 
By, 

Gregory W. Osterloth 
Attorney/Agent for Applicant(s) 
Reg No. : 36,232 
Date : September 14, 2006 

Telephone : (303) 291-3204 



Rev mre (ApIBrief) 



Appl. No. 

Appellant 

Filed 

TC/A.U. 

Examiner 



09/751,009 
Raja Daoud, et al. 
December 29, 2000 
2157 

Sail, El Hadji Malick 



Confirmation No. 6164 



Docket No. 



10002669-1 



Board of Patent Appeals and Interferences 
United States Patent and Trademark Office 



PO Box 1450 
Alexandria VA 22313-1450 



APPEAL BRIEF 



Table of Contents 



Section : 

Table of Contents 

Real Party in Interest 

Related Appeals and Interferences 

Status of Claims 

Status of Amendments 

Summary of Claimed Subject Matter 

Grounds of rejection to be Reviewed on Appeal 
Argument 

Claims Appendix 

Evidence Appendix 

Related Proceedings Appendix 




IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
BEFOR^E THE BOARD OF PATENT APPEALS AND INTERFERENCES 



Appl. No. 

Appellant 

Filed 

TC/A.U. 

Examiner 



09/751 ,009 
Raja Daoud, et al. 
December 29, 2000 
2157 

Sail, El Hadji Malick 



Confirmation No. 6164 



Docket No. 



10002669-1 



Board of Patent Appeals and Interferences 
United States Patent and Trademark Office 
PO Box 1450 

Alexandria, Virginia 22313-1450 

APPEAL BRIEF 



Dear Sir: 

This Appeal Brief is submitted in response to the Examiner's second Final 
Office Action, dated July 25, 2006. 

Appellants are filing a Notice of Appeal herewith, on September 14, 2006. 
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Real Party in Interest 



The real party in interest is Hewlett-Packard Development Company, LP, a limited 
partnership established under the laws of the State of Texas and having a principal 
place of business at 20555 S.H. 249 Houston, Texas 77070. U.S.A. (hereinafter 
"HPDC"). HPDC is a Texas limited partnership and is a wholly-owned affiliate of 
Hewlett-Packard Company, a Delaware Corporation, headquartered in Palo Alto, 
California. The general or managing partner of HPDC is HPQ Holdings, LLC. 
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Related Appeals and Interferences 



There are no related appeals and/or interferences. 
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Status of Claims 

Claims 1-5, 9, 14, 15, 17 and 18 are pending, all of which stand rejected. A copy 
of the claims is attached as a Claims Appendix to this Appeal Brief. 
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Status of Amendments 



All amendments have been entered. 
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Summary of Claimed Subject Matter 

The following provides a concise explanation of the subject matter defined in 
each of the claims involved in the appeal, referring to the specification by page and 
line number and to the drawings by reference characters, as required by 37 C.F.R. 
§41 .37(c)(1 )(v). Each element of the claims is identified by a corresponding 
reference to the specification and drawings where applicable. Note that the citation 
to passages in the specification and drawings for each claim element does not imply 
that the limitations from the specification and drawings should be read into the 
corresponding claim element. 

In one embodiment (claim 1), apparatus for identifying a requested level of 
service (p. 3, line 28) for a transaction (p. 3, line 30) comprises computer readable 
program code (p. 15, line 15) stored in computer readable storage media (p. 15, line 
16). The program code comprises: program code for prompting a user to select a 
requested level of service for said transaction (p. 9, lines 21-23; FIG. 8, 800); and 
program code for assigning said requested level of service to said transaction (p. 16, 

lines 18-20; FIG. 8, 810). 

In another embodiment (claim 5), apparatus for identifying a requested level of 
service for a transaction (p. 3, line 30) comprises computer readable program code 
(p. 15, line 15) stored in computer readable storage media (p. 15, line 16). The 
program code comprises: program code for selecting said requested level of service 
for said transaction (p. 9, lines 21-23; FIG 8, 800), said requested level of service 
being based on a user identification (p. 7, line 30-p. 8, line 9; p. 9, lines 15-19); and 
program code for assigning said requested level of service to said transaction (p. 16, 

lines 18-20; FIG. 8, 810). 

In yet another embodiment (claim 9), a method for requesting a level of service 
for a transaction on a network (p. 16, lines 12-12; FIG 8, 800) comprises: selecting 
said requested level of service for said transaction via a user interface (p. 9, line 22); 
and assigning said requested level of service to said transaction (p. 16, lines 18-20; 
FIG. 8, 810). 
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In still another embodiment (claim 14), apparatus for routing (p. 15, line 13) a 
transaction over a network based on a requested level of service associated with 
said transaction (p. 15, lines 13-16) comprises computer readable program code (p. 
15, line 15) stored in computer readable storage media (p. 15, line 16). The 
computer readable program code comprises: a) program code for selecting said 
requested level of service for said transaction (p. 9, lines 21-23; FIG 8, 800); b) 
program code for assigning (p. 16, lines 18-20; FIG. 8, 810) a service tag (FIG. 2, 
200) to said transaction , said service tag including said requested level of service (p. 
7, lines 17-19), and said program code assigning parts of said service tag at more 
than one point on said network (p. 17, lines 9-13; FIG. 9, 910, 925, 935, 930, 940, 
945); c) program code for reading said requested level of service from said service 
tag (p. 1 1 , lines 11-16); and d) program code for directing said transaction over said 
network based on said requested level of service read from said service tag(FIG. 3; 
p. 10, lines 18-23). 
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Grounds of Rejection to be Reviewed on Appeal 

I. Whether claims 1, 3, 4, 5 and 9 should be rejected under 35 U.S.C. 102(e) as 
being anticipated by U.S. Pat. No. 6,871,233 to Bearden et al. 

II. Whether claims 14, 15, 17, and 19 should be rejected under 35 U.S.C. 102(e) as 
being anticipated by U.S. Pat. No. 6,483,805 to Davies et al. 

III. Whether claim 2 should be rejected under 35 U.S.C. 1 03(a) as being unpatentable 
over U.S. Pat. No. 6,871,233 to Bearden et al. in view of U.S. Pat. No. 6,483,805 to 
Davies et al. 
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Argument 

I. Claims 1, 3 f 4, 5 and 9 should not be rejected under 35 U.S.C. 102(e) as 
being anticipated by U.S. Pat. No. 6,871,233 to Bearden et al. (hereinafter 
"Bearden"). 

a. Claims 1 and 4 

Appellants' claim 1 recites: 

1 . An apparatus for identifying a requested level of service for a transaction, 
comprising: 

computer readable storage media; and 

computer readable program code stored in said storage media, 
comprising: 

a) program code for prompting a user to select a requested level of 
service for said transaction; and 

b) program code for assigning said requested level of service to said 
transaction. 

In rejecting claim 1 , the Examiner asserts that: 

.Bearden teaches an apparatus for identifying a requested level of 
service for a transaction, comprising: 

computer readable storage media (figure 3, item 301); and 
computer readable program code stored in said storage media, 
comprising: 

a) program code for prompting a user to select a requested level 
of service for said transaction (column 1 , lines 54-67; column 4, lines 
20-25); 

b) program code for assigning said requested level of service to 
said transaction (column 2, lines 3-7). 

7/25/2006 Final Office Action, sec. 3, p. 3. 

Appellants respectfully disagree. Bearden fails to show "a) program code for 
prompting a user to select a requested level of service for said transaction...". 
Instead, Bearden teaches how a user, such as an administrator, can: 
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...specify parameters for predefined types of service level QoS goals. 
A QoS goal is defined by specifying a client, a service and a QoS 
expression. A QoS expression is a proposition that indicates the 
client's desired range of values for some QoS metric, e.g., service 
response time or service availability. 

Bearden col. 1 , lines 56-61 . 

As shown in Bearden's FIG. 4, and specifically in decision boxes 41 1 and 412, 
and in steps 417 and 418, Bearden's QoS goals cause the network resources 
assigned to a particular client to be increased or decreased based on whether a QoS 
goal was met (or not) for past transactions. Thus, the client is not prompted to 
"select a requested level of service" for any particular transaction, but is only 
prompted to specify a QoS goal for all transactions. The QoS goal is then 
enforced by a management server 301 (FIG. 3) which automatically allocates and 
de-allocates network resources to increase or decrease the QoS given to a current 
transaction, in response to the QoSs that were actually provided to past transactions. 
An overall QoS goal for a group of transactions is thereby maintained. If a 
user wants to request a particular level of service for any particular 
transaction, it appears that Bearden offers no way to do this. 

Claim 1 is believed to be allowable for at least the above reasons. 

Claim 4 is believed to be allowable, at least, because it depends from claim 1 . 



b. Claim 3 

With respect to claim 3, the Examiner asserts that Bearden teaches "program 
code for selecting a backup level of service" in FIG. 4, and in col. 5, line 45 - col. 6, 
line 24. Appellants disagree. The Examiner's cites only refer to allocating and de- 
allocating network resources to achieve a single QoS goal (or single set of goals). 
Appellants cannot find any mention of anything corresponding to a "backup level of 
service". 
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Claim 3 is believed to be allowable because it depends from claim 1, and for 
the additional reasons cited in the above paragraph. 



c. Claim 5 



Appellants' claim 5 recites: 

An apparatus for identifying a requested level of service for a 
transaction, comprising: 

computer readable storage media; and 

computer readable program code stored in said storage media, 
comprising: 

a) program code for selecting said requested level of service for said 
transaction, said requested level of service being based on a user 
identification; and 

b) program code for assigning said requested level of service to said 
transaction. 

In rejecting claim 5, the Examiner asserts that: 

. . .Bearden teaches an apparatus for identifying a requested level of 
service for a transaction, comprising: 

computer readable storage media (figure 3, item 301); and 
computer readable program code stored in said storage media, 
comprising: 

a) program code for selecting said requested level of service for 
said transaction, said requested] level of service being based on a 
user identification (column 1 , lines 54-67; column 4, lines 20-25; 
Column 2, lines 8-11); 

b) program code for assigning said requested level of service to 
said transaction (column 2, lines 3-7). 

7/25/2006 Final Office Action, sec. 3, p. 4. 

Appellants respectfully disagree. Bearden fails to show "a) program code for 
selecting said requested level of service for said transaction, said requested level of 
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service being based on a user identification...". Instead, Bearden teaches how a 
user, such as an administrator, can: 

...specify parameters for predefined types of service level QoS goals. 
A QoS goal is defined by specifying a client, a service and a QoS 
expression. A QoS expression is a proposition that indicates the 
client's desired range of values for some QoS metric, e.g., service 
response time or service availability. 

Bearden col. 1, lines 56-61. 

As shown in Bearden's FIG. 4, and specifically in decision boxes 41 1 and 412, 
and in steps 417 and 418, Bearden's QoS goals cause the network resources 
assigned to a particular client to be increased or decreased based on whether a QoS 
goal was met (or not) for past transactions. Thus, the client is not prompted to 
"select a requested level of service" for any particular transaction, but is only 
prompted to specify a QoS goal for all transactions. The QoS goal is then enforced 
by a management server 301 (FIG. 3) which automatically allocates and de-allocates 
network resources to increase or decrease the QoS given to a current transaction, in 
response to the QoSs that were actually provided to past transactions. An overall 
QoS goal for a group of transactions is thereby maintained. There appears to be no 
way to select a "requested level of service for [a] transaction. . .based on a user 
identification" (emphasis added). 

Claim 5 is believed to be allowable for at least the above reasons. 

d. Claim 9 

Claim 9 is believed to be allowable, at least, for reasons similar to why claim 1 
is believed to be allowable. 
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II. Claims 14, 15, 17, and 19 should not be rejected under 35 U.S.C. 102(e) as 
being anticipated by U.S. Pat. No. 6,483,805 to Davies et al. (hereinafter 

"Davies"). 

Appellants' claim 14 recites: 

An apparatus for routing a transaction over a network based on 
a requested level of service associated with said transaction, 
comprising: 

a number of computer readable storage media; and 
computer readable program code stored in said number of 
storage media, comprising: 

a) program code for selecting said requested level of 
service for said transaction; 

b) program code for assigning a service tag to said 
transaction, said service tag including said requested level of 
service, and said program code assigning parts of said service 
tag at more than one point on said network; 

c) program code for reading said requested level of 
service from said service tag; and 

d) program code for directing said transaction over 
said network based on said requested level of service read from 
said service tag. 

The Examiner states, "a) program code for selecting said requested level of 
service for said transaction [is taught by Davies at] column 7, lines 47-59..." (see, 
7/25/2006 Final Office Action, sec. 4, p. 5). Appellants respectfully disagree. 

Davies states: 

Because of the nature of the packet traffic generated by an 
application requiring a transactional service (for example web page 
request and download) it is difficult to create such a Service Level 
Agreement based on a single class for such packets. The network is 
unable to predict or readily control the load imposed by traffic of this 
nature. 

Davies, column 7, lines 47-59. 

Appellants fail to appreciate the relevance of the cited reference and find no 
teaching or suggestion of the claimed limitation. Ignoring for the moment that the 
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reference routes packets, as opposed to directing transactions, the reference 
appears to be teaching away from the Appellants' claim 14. While Davies finds it 
"difficult to create" a single class of packets for a transaction for predicting and 
controlling the load of such packets, claim 14 selects level of service for a 
transaction, assigns a service tag to a transaction, and then directs the transaction 
accordingly. 

The Examiner also asserts that: 

b) program code for assigning a service tag to said transaction, 
said service tag includes said requested level of service, and said 
program code assigning parts of said service tag at more than one 
point on said network [is taught by Davies at] column 6, line 66 to 
column 7, line 6 [and] column 8, line 62 to column 9, line 4... 

7/25/2006 Final Office Action, sec. 4, p. 5. 

Appellants disagree. Davies teaches, "...marking each individual packet used 
to deliver data across an IP network with a code comprising a small number of bits. 
(Davies, col. 6, line 66 - col. 7, line 6). Appellants' claim 14 recites, "assigning a 
service tag to [a] transaction". 

Davies at column 8, line 62 to column 9, line 4 discusses the throttling of the 
data flow sent by a TCP source via a windowing mechanism. Appellants fail to 
appreciate the relevance of the reference and find no teaching or suggestion of the 
claimed limitation. 

The Examiner then asserts that: 

c) reading said requested level of service from said service; and 
d) directing said transaction over said network based on said requested 
level of service read from said service tag [is taught by Davies at] 
column 7, lines 34-45. 

7/25/2006 Final Office Action, sec. 4, p. 5. 
Appellants disagree. What Davies teaches is: 
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Routers which process the packets as they are forwarded 
across the IP network inspect the code and treat each packet marked 
with the same value in the same way when determining the priority or 
preference to give to those packets on the next hop of their path 
through the network. Each set of similarly-marked packets 
constitutes an [sic] class, and by applying different treatments to 
different classes a different quality of service can be obtained for 
each class. For example, access to a portion of the network may be 
refused to traffic in a given class which exceeds, in some measurable 
way, a previously agreed contract typically known Service Level 
Agreement (SLA). 

Davies, column 7, lines 34-45. 

Appellants' claim 14 teaches the reading of a level of service from a 
transaction's service tag and directing the transaction accordingly, whereas 
Davies routes packets. Davies' purpose for placing "a small number of bits" on a 
packet is to lump certain "bits" into classes. The classes are then subject to class- 
specific routing. Routing is the passive execution of processes to allow a packet to 
reach its intended destination. Directing, as in claim 14, actively determines where 
the transaction is to go. 

For at least the above reasons, claim 14 is believed to be allowable. Claims 
15, 17, and 18 are believed allowable for at least the reason that they depend from 
claim 14. 



Ill Claim 2 should not be rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Pat. No. 6,871,233 to Bearden et al. (hereinafter 
"Bearden") in view of U.S. Pat. No. 6,483,805 to Davies et al. (hereinafter 

"Davies") 

Appellants' claim 2 recites: 

An apparatus, as in claim 1 , wherein said transaction is a 
packetized signal comprising at least a data packet, and wherein a 
service tag is associated with said data packet by said program code 
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for assigning said requested level of service, said service tag including 
said requested level of service- 
Appellants believe claim 2 is allowable, at least, for the reason that it depends 
from claim 1 , which is believed to be allowable over Bearden. See, Section 1 of 
these Remarks/Arguments, supra. Davies fails to teach what is missing from 
Bearden. 

Furthermore, the references lack any suggestion to be combined, and such a 
combination would be counterintuitive. Davies teaches the routing of packets 
(Davies, abstract). It is known in the art that packets may be a portion of data or a 
transaction. A solution that is indifferent to a packet's content, that is, if the packet is 
a transaction, a portion of a transaction, or, for example, a video file, is unlikely to be 
considered a viable solution to transaction routing. Davies also views the problem of 
managing individual flows of packets, let alone individual packets, as an 
impossibility. 

To avoid problems of scalability in the core of large networks, 
where there are many hundreds or thousands or millions of flows of 
packets the QoS cannot be specified at the granularity of 
individual flows in the core of the network. The treatment of packets 
in the core of the network to achieve the desired QoS must be very 
simple- there is very little time and processing effort available for each 
packet in a network core device in which a new packet may be arriving 
as frequently as every 50-100 ns. 

Davies, p. 6, lines 41-49. 

Claim 2 is believed to be allowable for at least the above reasons. 



-16- 



Appl. No. 09/751,009 

Appeal Brief dated Sep. 14, 2006 

Reply to Final Office Action of July 25, 2006 



Conclusion 



In summary, the art of record does not teach nor suggest the subject matter of 
Appellants' claims 1-5, 9, 14, 15, 17 and 18. These claims are therefore believed to 
be allowable. 



Respectfully submitted, 
DAHL & OSTERLOTH, L.L.P. 



By: 




Gregory W. Osterloth 
Reg. No. 36,232 
Tel: (303)291-3200 
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Claims Appendix 

1 . An apparatus for identifying a requested level of service for a transaction, 
comprising: 

computer readable storage media; and 

computer readable program code stored in said storage media, comprising: 

a) program code for prompting a user to select a requested level of service 
for said transaction; and 

b) program code for assigning said requested level of service to said 
transaction. 

2. An apparatus, as in claim 1, wherein said transaction is a packetized signal 
comprising at least a data packet, and wherein a service tag is associated with said 
data packet by said program code for assigning said requested level of service, said 
service tag including said requested level of service. 

3. An apparatus, as in claim 1, further comprising: 

a) program code for selecting a backup level of service; and 

b) program code for assigning said backup level of service to said 
transaction. 

4. An apparatus, as in claim 1 , wherein said requested level of service is a 
predefined service category. 

5. An apparatus for identifying a requested level of service for a transaction, 
comprising: 

computer readable storage media; and 

computer readable program code stored in said storage media, comprising: 
a) program code for selecting said requested level of service for said 
transaction, said requested level of service being based on a user identification; 
and 
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b) program code for assigning said requested level of service to said 
transaction. 

6. (canceled) 

7. (canceled) 

8. (canceled) 

9. A method for requesting a level of service for a transaction on a network, 
comprising: 

selecting said requested level of service for said transaction via a user 
interface; and 

assigning said requested level of service to said transaction. 

10. (canceled) 

11. (canceled) 

12. (canceled) 

13. (canceled) 

14. An apparatus for routing a transaction over a network based on a requested 
level of service associated with said transaction, comprising: 

a number of computer readable storage media; and 
computer readable program code stored in said number of storage media, 
comprising: 

a) program code for selecting said requested level of service for said 
transaction; 

b) program code for assigning a service tag to said transaction, said service 
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tag including said requested level of service, and said program code assigning 
parts of said service tag at more than one point on said network; 

c) program code for reading said requested level of service from said service 
tag; and 

d) program code for directing said transaction over said network based on 
said requested level of service read from said service tag. 

15. An apparatus, as in claim 14, wherein said transaction is directed over said 
network to a device best providing said requested level of service. 

16. (canceled) 

17. An apparatus, as in claim 14, wherein said service tag is read by program code 
at more than one point on said network. 

18. An apparatus, as in claim 14, further comprising program code for changing 
said requested level of service included on said service tag. 

19. (canceled) 

20. (canceled) 
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Evidence Appendix 



None. 



B-1 



Appl. No. 09/751,009 

Appeal Brief dated Sep. 14, 2006 

Reply to Final Office Action of July 25, 2006 



Related Proceedings Appendix 



None. 
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